feat: add a VA-API H.264 decoder - #2

The mirror of `encode`: one Annex-B access unit in, tightly-packed NV12
out. It gives moq-video a hardware H.264 decode path on Intel and AMD,
next to the NVDEC one it already has for NVIDIA.

The bitstream layer this needs was already vendored here and unused by
the encode path: `codec::h264::parser` parses SPS, PPS, and slice
headers, `codec::h264::dpb` implements reference picture list
construction, the MMCO operations, sliding-window marking, and the C.4.5
bumping process, and `codec::h264::picture` holds the per-picture state.
What was missing is the layer above (picture order count, reference list
modification, and the finish-picture sequence, ported from cros-codecs's
`decoder/stateless/h264.rs`) and the layer below (the VA picture, IQ
matrix, and slice parameter buffers, ported from its
`decoder/stateless/h264/vaapi.rs`). Neither of the two generic
frameworks in between is vendored: `decode::Decoder` drives libva
directly, the way `encode::Encoder` does.

Deliberately narrower than upstream:

- Progressive 8-bit 4:2:0 only. An interlaced, high-bit-depth, or
  non-4:2:0 sequence is rejected at the first SPS instead of decoded
  wrongly, which drops field pairing, frame splitting, and the
  second-field surface sharing that dominate the upstream state machine.
- A picture is completed when the access unit that carries it ends,
  rather than when the next unit's first slice arrives, so the hardware
  is never left holding a half-submitted picture between calls. Output
  still trails by a picture, since C.4.5.3 bumps the DPB only when a new
  picture needs the slot.
- Baseline maps to VAProfileH264ConstrainedBaseline whether or not
  constraint_set0_flag is set. VA-API cannot express the FMO and ASO
  tools that separate the two (the picture parameter buffer pins
  num_slice_groups_minus1 to 0), so requiring the flag only refuses
  streams the hardware would decode correctly anyway.

Surfaces come from a small pool that recycles them once the DPB and the
output queue are done with a picture, and are read back with
vaDeriveImage, falling back to vaCreateImage + vaGetImage on a driver
that cannot derive.

Verified on Intel Meteor Lake (iHD 26.1.5) against ffmpeg's software
decoder, byte-for-byte identical NV12 output for: constrained baseline
320x240, main 320x240 with B-frames, high 1280x720, high 642x358 (a
cropped, non-macroblock-aligned size), and a stream that changes
resolution mid-play. 600 frames of 720p with a B-pyramid decode in 1.2 s
including the CPU download.

`flush` was here from the start but nothing exercised what it is for, and
the module doc understated it: it said output trails by a picture for a
stream without reordering, which is only true of a stream coded with one
reference frame. C.4.5.3 bumps the DPB when a new picture needs a slot,
so the delay follows the sequence's reference and reorder limits rather
than the reorder depth actually used, and a stream simply stopping leaves
that whole tail behind.

Measured on Intel Meteor Lake (iHD 26.1.5) against a six-picture x264
stream: with its defaults (ref=3, B-frames) four pictures come out of
`decode` and two out of `flush`; with ref=3 and no B-frames at all it is
three and three. This crate's own IPPP encoder holds one back, which is
what the new test asserts, along with the flush returning exactly the
pictures decode did not and a second flush returning nothing.

The test would be vacuous against a decoder that held nothing back, so it
asserts that `decode` came up short before it asserts that `flush` makes
up the difference.

An exported frame carried only its DRM PRIME descriptor, which keeps the
allocation alive but names nothing that can be mapped, and a decode target
is tiled so reading the descriptor as rows would be wrong. A caller that
took a picture on the GPU therefore had no way back to its pixels, which is
what stopped GPU-resident output being something a decoder could offer
without also taking the CPU path away.

The pool surface is now behind an `Arc` and travels with the descriptor,
so `ExportedFrame::download` reaches the picture through the same
`vaDeriveImage` path a downloaded `Frame` takes. Retiring is unchanged: an
exported surface still leaves the pool, so a later picture cannot be
decoded over one a consumer holds. `ExportedFrame` is `Send` and `Sync` on
its own, since a surface is a display and an id and none of the decoder's
`Rc`s come along.

8.2.1.1 compares pic_order_cnt_lsb against prevPicOrderCntLsb, which is
zero for an IDR and the previous reference picture's TopFieldOrderCnt
after an MMCO 5. The first of the two conditions read the raw cached lsb
instead, so a picture following an MMCO 5 could take the wrong branch and
land a whole MaxPicOrderCntLsb away from where it belongs. The second
condition already used the right value, which is what makes this a slip
rather than a reading of the clause.

8.2.1.2 sums offset_for_ref_frame only up to the position the frame sits
at within the cycle. Summing the whole cycle gives every picture the same
expected order count, so a pic_order_cnt_type 1 stream came out in decode
order rather than output order.

Neither is reachable from the streams the tests cover: x264, this crate's
encoder, and browser encoders all code pic_order_cnt_type 0 and none of
them emit MMCO 5.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Reject left/top cropping before sequence reuse and include visible dimensions in sequence identity. Build progressive VA picture heights directly from the SPS map-unit count. Add hardware-independent regressions and run unit tests in CI.

Co-Authored-By: GPT-6 <noreply@openai.com>